IBIS Macromodel Task Group Meeting date: 28 March 2023 Members (asterisk for those attending): Achronix Semiconductor: Hansel Dsilva Amazon: John Yan ANSYS: * Curtis Clark Wei-hsing Huang Aurora Systems: Dian Yang Cadence Design Systems: * Ambrish Varma Jared James Google: Hanfeng Wang GaWon Kim Intel: * Michael Mirmak * Kinger Cai Chi-te Chen * Liwei Zhao Keysight Technologies: Fangyi Rao Majid Ahadi Dolatsara * Stephen Slater * Ming Yan Rui Yang Luminous Computing David Banas Marvell Steve Parker Mathworks (SiSoft): Walter Katz * Graham Kus Micron Technology: * Randy Wolff Justin Butterfield Missouri S&T Chulsoon Hwang Yifan Ding Rivos Yansheng Wang SAE ITC Michael McNair Siemens EDA (Mentor): * Arpad Muranyi Teraspeed Labs: * Bob Ross Waymo: Zhiping Yang Zuken USA: * Lance Wang The meeting was led by Arpad Muranyi. Curtis Clark took the minutes. -------------------------------------------------------------------------------- Opens: - Liwei Zhao introduced herself. She works on platform design and has interests in clock and jitter analysis. She has been working on developing IBIS models and works with Michael Mirmak on IBIS related topics. ------------- Review of ARs: Stephen: Socialize the SPIM proposal/BIRD with experts in the field and gather their feedback. - Done, see discussion below. Kinger: Add additional scenario explanations and examples to the PSIJ Sensitivity BIRD draft and send out draft9. - Done. Arpad: Prepare a presentation and statement of the issue for the AMI_GetWave block size with continually adapting models topic. - Not Done. -------------------------- Call for patent disclosure: - None. ------------------------- Review of Meeting Minutes: Arpad asked for any comments or corrections to the minutes of the March 21st meeting. Kinger moved to approve the minutes. Michael seconded the motion. There were no objections. -------------- New Discussion: SPIM BIRD223 feedback: Stephen said several experts in his organization had reviewed the proposal and been in touch with Kinger. He said there was some confusion at the outset, as they had expected it to contain information about how the VRM model is operating. Once they had realized it was more about how the package and die are operating, and it provides target impedance, current draws per pin, etc., then they thought it was a reasonable representation. Their primary feedback was that the frequency domain approach is good for target impedance and small signal analysis, but the model will need to be used in large signal simulations eventually. In the future, we will need to be able to include VRM models that support transient simulation and properly capture feedback loops and other transient effects. As long as the model can do that in the future, they were okay with the proposal. Kinger thanked Stephen for helping to gather the feedback. He said there might be a misconception about the SPIM model. Even though SPIM contains frequency domain data, it is intended for large signal applications. He said they were originally interested in developing models for the rails with the largest current draw, such as the compute rails. The goal is to give the platform designer a PI target and have the SPIM model support platform PI design in the same way that the IBIS [Model] supports platform SI design. Kinger said the chip vendor understands best where the heavy and light loads on the chip exist. Once the chip vendor has settled on the PI design at the Si and package level, then SPIM lets them share a sufficient but minimal set of information to the platform designer for their PI design and verification. For the platform designer, as long as they meet the impedance target profile, they can be assured their design will work with the chip. Transient simulation is a future goal for SPIM, but it is not necessary to provide the platform designer with information to support transient simulation. Trying to provide transient model information to the platform designer introduces many additional complications and potential issues with exposing sensitive IP. Kinger said it is a lengthy BIRD. He welcomed additional feedback and said he was willing to have offline discussions with anyone requiring more information. Arpad encouraged everyone interested in the proposal to subscribe to the IBIS ATM list. BIRD draft for IBIS-AMI Ts4file port order: Liwei introduced the proposal. She said it aims to allow additional options for specifying the port ordering used to connect the .s4p file specified in the AMI Reserved Parameter Ts4file. The specification currently specifies a fixed port ordering (defined in Figures 46 and 47 of IBIS 7.2). The proposal introduces two new Reserved Parameters Tx_Port_Order and Rx_Port_Order, which specify the port ordering for Tx and Rx directions, respectively. The allowed values are "IEEE", "Gonzalez" and "Auto". "IEEE" corresponds to the existing port ordering in IBIS 7.2. "Gonzalez" would correspond to a 1,2 on the left and 3,4 on the right ordering. "Auto" would specify that the tool decides which way the .s4p should be connected. Ming asked how we could expect the EDA tool to determine the proper order for connection. Liwei said the EDA tool could look for the passthrough channels. Ming asked how the EDA tool would determine which direction is the input or the output. Liwei said we could define that port 1 is an input and work from there. Arpad agreed with Ming's question. He said, considering only the Tx direction for this example, how would the tool know port 1 is on the stimulus side and not port 3. The tool can determine the low impedance path between two ports to decide between IEEE or Gonzalez ordering, but how could it know which direction from input to output? Randy said we already have limitations on the way .s4p files are included in a Tx or Rx AMI model. This proposal does not intend to allow complete freedom in port ordering. There will simply be two possible orderings instead of just one. The tool could potentially figure out which of those 2 possibilities to use. Arpad suggested that this BIRD should have additional figures to illustrate the Gonzalez ordering. Arpad asked how people felt in general about adding another possible ordering. He asked whether people saw a big need for this. Randy said he'd occasionally been forced to use tools to reorder the ports of an .s4p to adjust to what IBIS Ts4file requires. However, he also noted that he'd been given .s4p files for which 1 and 2 were the negative terminals instead of the positive terminals. So, not even this proposal can accommodate all of the possibilities. Arpad asked if this proposal was enough, in that case. Ming said he was okay with adding an additional option (Gonzalez), but he did not like the idea of "Auto". Curtis agreed with Ming. Stephen asked why this was necessary. Shouldn't it be on the model maker to deliver the .s4p in the proper order? He asked if these parameters would simply confuse users. Arpad said the parameters are Info parameters intended only to tell the tool how to connect the .s4p. Stephen said it should be straightforward for the model maker to reformulate their S-parameters into the order prescribed for the Ts4file. Michael said Randy's experience hinted at some of the issues model makers face. There may be multiple teams working on a project. One team generates the .s4p and another team uses it or tells Application Engineers to fix the ordering. Arpad and Randy suggested that instead of "IEEE" and "Gonzalez", we might come up with a way to specify ordering using a string containing the numbers 1, 2, 3, 4, as is done in the [Two-Port Data Order] keyword in the Touchstone 2.0 specification. Arpad said this could allow for all connection orders. Randy wondered whether anyone would want a way to specify more possible orderings. Liwei said she would email the proposal to the ATM list. Bob asked that she send it out with "draft1" appended to the name. PSIJ Sensitivity BIRD draft: Kinger reviewed draft9, which he had sent to the ATM list prior to the meeting. He had added a new paragraph explaining how jitter sensitivity effects are specified for individual signals via the [PSIJ Sensitivity Signal] keyword. Referring to one of the new examples: [PSIJ Sensitivity Signal] DQ DQS Arpad asked whether we should add a subparameter with the list of signal names. He said that usually keywords that have names are using the names so that we can support multiple instances of the keyword. Randy said the names in Kinger's examples helped to understand the concept. They're trying to list all of the affected address, clock, data, etc., signals. However, if we want to tie it to something meaningful in the IBIS specification, we might want to tie the names to IBIS [Model]s or [Model Selector]s. If all the pins of a certain type share a [Model Selector], the [PSIJ Sensitivity Signal] information could apply to all of them. Kinger said "DQ DQS" was not intended to mean that the [PSIJ Sensitivity Signal] applied individually to the DQ and DQS signals. He said the intent was to state that it captures the effects on the DQ signal, which is clocked by the DQS signal. That is, it would be used to compute the jitter distribution to be applied to the DQ signal eye diagram, and it would include the contributions of the PSIJ effects on the associated DQS clock as well. - Michael: Motion to adjourn. - Ambrish: Second. - Arpad: Thank you all for joining. New ARs: Liwei: Send out draft1 of the IBIS-AMI Ts4file port order BIRD proposal. ------------- Next meeting: 04 April 2023 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives